An IMS introduces an idea of separating control from bearer into an IP-based communication network. The IMS is a core in service processing of the communication network. High reliability of the IMS is the basis of high reliability of the entire communication network.
To improve reliability of the IMS, the network disaster recovery capability must be improved. An IMS network includes multiple network entities, between which there is a strong association. The network disaster recovery capability means that when a network device fails, the failure of the network device has the least impact on the entire IMS network and on users.
In some other approaches, after registering with an IMS network successfully, a user equipment (UE) starts a registration timer immediately according to a negotiated registration period, and re-registration of the UE is triggered when the registration timer expires. If a Serving Call Session Control Function (S-CSCF) that provides services for the user fails, a new S-CSCF may be assigned to the user through a mechanism of re-registration triggered by a registration timer.
According to the foregoing descriptions, when the S-CSCF that provides services for the user fails, the network service of the UE can be recovered after the registration timer of the user triggers re-registration and an S-CSCF is re-selected. That is, the service interruption duration of the UE depends on the registration period of the UE. The longer the registration period is, the longer the service interruption duration will be. To meet the reliability requirements of a telecom network, the registration period should be as short as possible. But if the registration period is set to a too small value, re-registration will occur frequently. With regard to the network, frequent re-registration increases the processing load of the network, and especially, frequent re-registration occupies valuable air-interface resources of a radio access network (RAN). With regard to the UE, frequent re-registration consumes the limited energy of the UE and shortens the standby time of the UE.
A solution to the foregoing problems is available in the other approaches. That is, during registration, the S-CSCF backs up the registration-related user data, such as the IMS Private User Identity (IMPI) information, IMS Public User Identity (IMPU) information, registered Contact address, and path information, to a Home Subscriber Server (HSS). When the S-CSCF fails and a UE uses the network, an Interrogating CSCF (I-CSCF) may select another S-CSCF to provide session services for the UE, and the new S-CSCF may obtain the user backup data of the IMPU that uses services in order to recover related services of the UE, thus implementing disaster recovery of the S-CSCF.
Currently, user identifiers (IDs) used in an IMS network mainly include an IMPI and an IMPU that are saved in an HSS in subscription mode. When a user performs a related service operation, the related entities in the network such as an I-CSCF, an S-CSCF, and an Application Server (AS) obtain the subscription data of the user through a user ID. In the IMS, the relation between user IDs and the relation between user IDs and subscription data are complex. As shown in FIG. 1, one IMS subscription includes all subscription information that may be transmitted by one UE on a Cx interface. One IMS subscription may include multiple IMPIs, but one IMPI belongs to only one IMS subscription, one IMPI may include multiple IMPUs, and one IMPU may be shared by multiple IMPIs. That is, the IMS subscription is in a one-to-many relation with the IMPI, and the IMPI is in a many-to-many relation with the IMPU. Therefore, the service logics such as one-IMPI multi-IMPU, one-IMPU multi-IMPI, and multi-IMPI multi-IMPU can be implemented flexibly.
When implementing the disclosure, the inventor finds at least the following problem in the foregoing technical solution to IMS disaster recovery. In the other approaches, no detailed recovery solution is worked out against the complex user data model in the IMS. Therefore, when adopting the foregoing technical solution, the one-IMPU multi-IMPI and multi-IMPI multi-IMPU services of users may be lost, thus reducing service continuity experiences of the users. For example, when the user data model shown in FIG. 2 is taken as an example, processing of the IMS disaster recovery solution in the other approaches is as follows.
Assuming that all IMPI and IMPU instances in the IMS subscription shown in FIG. 2 are registered on an S-CSCF1. If the S-CSCF1 fails and if a UE (IMPI1 and IMPU3) associated with the service performs periodic re-registration, a registration request is forwarded to an S-CSCF2 according to the foregoing technical solution. The S-CSCF2 registers the IMPI1 and IMPU3 successfully through a standard registration process and recovers user backup data of the IMPI1 and IMPU3 to the S-CSCF2. In addition, an HSS changes the server name saved for the IMS subscription from S-CSCF1 to S-CSCF2, and then may send a Registration Termination Answer (RTA) message to the original S-CSCF (S-CSCF1) to notify that a UE migration process is optional and that even if the RTA message is sent, the sending fails because of the failure of the original S-CSCF. Up to now, the disaster recovery process caused by UE (IMPI1 and IMPU3) registration is complete. If the IMPU3 is called: after receiving a call request, an I-CSCF searches the HSS for an S-CSCF (S-SCCF2) that serves the IMPU3 (in fact, the IMS subscription), the S-CSCF2 is in the normal state, and therefore, the I-CSCF does not add a disaster recovery flag to the call request, but routes the request to the S-CSCF2 directly, after receiving the request, the S-CSCF2 determines that the IMPU3 has a registered terminal IMPI1 locally, and that the call request does not contain a disaster recovery flag, so the S-CSCF2 does not perform disaster recovery, but analyzes whether to send the call request to the IMPI1, as a result, the one-IMPU multi-IMPI service (IMPI1 and IMPI2) of the IMPU3 is lost.